How to handle $side within a present field?

In principle, this would be a good fit for the cycleway field type (see the Special section in the schema -builder docs).

{
  "keys": [
      "parking:both",
      "parking:left",
      "parking:right"
  ],
  "type": "<<cycleway>>",
  "label": "Street Parking Type",
  "strings": {
      "types": {
          "parking:left": "Left side",
          "parking:right": "Right side"
      },
      "options": {
          "lane": "Roadside Lane",
          "street_side": "Street-Side",
          "on_kerb": "On Kerb",
          "half_on_kerb": "Half On Kerb",
          "shoulder": "Shoulder",
          "no": "No",
          "separate": "Parking mapped separately",
          "yes": "Yes (unspecified)"
      }
  },
  "autoSuggestions": false,
  "customValues": false
}

However, the implementation is pretty much hardcoded for the literal cycleway:* key on iD's side. It wouldn't be too hard to generalize this into a reusable ("type": "directional") field type.

For this type of field, it would make sense if the prerequisiteTag feature would also look at the corresponding $side subtags: e.g., if parking:left is no or empty and parking:right is set, only the parking:right:orientation input field should be enabled. I'm however not jet sure how to best model it in the schema. Probably it would make the most sense to be able to reference another field as a prerequisite in such cases:

"prerequsiteTag": {
    "field": "parking/side"
}

@tyrasd thanks for the input in your comment above and the update on iD. I updated this PR-description with a list of things that need to happen next from my point of view.

Would you be up to merging this with "must have" solved? And handle the other issues as follow ups?

On the topic of prerequisiteTag:

This needs an update to the schema-builder. But how to specify best, what we want? IMO, we want…

The field should appear if …

• any of the keys parking:left,parking:right,parking:both is present
• AND the values are not separate, no

We need the "not" part, since we don't users to provide an :orientation when so side was given.

This has two issues:

• We need to check combinations of key+value, right? Only if all given keys have a value of separate, no, the field should be hidden. Otherwise …

• If parking:right=no|separate, then parking:right:orientation should not be visible. Which would be another feature of the directionalCombo. Either the field should be deactivated; or a validation should warn users once they added data that this is (possible/doable but) wrong.

  Maybe we could work around this, by only showing :orientation directionalCombo fields if :right, :left is given, and a regular dropdown if :both is given.

Update 2022-12-29: In 47f61c8#diff-ffcc47af10b2693db223dcfd1da1260b54c5524e4af34ba8d4776ee24cb041eaR21-R79 I added a bit of code to experiment with options to solve the requirement to extend the prerequisiteTag.

Let me know what you think.

I will close this now in favor of #744.

It will be a while until the prerequisiteTag is extended enough to add more fancyness to this feature. And likely openstreetmap/iD#9476 will be a first step by manually handling those cases in iD.